This is just describing what obviously happens below with 7 lines of prose?

This is repeating what comments below says.

This paragraph is listing example without actually clarifying anything - exactly how do they appear in the module lookup algorithm, and with what precedence?

These implementation details should not be enumerated in the docs.

These look like random hand-wavy examples that seem to be meaningful but actually clarify nothing again - if we have to explain with an example it's better to provide a snippet etc. to make it more concrete.

Again we should not enumerate them here. If we must, simply linking to the documentation in packages is better.

The "instead of continuing into the real file system" part is leading users to spare a thought about a case that is not practical in the first place, because the mount point cannot actually have real files in the file system, no continuation can be performed even if Node.js wants to. I think it's clearer to simply list an example lookup, for example in /foo/bar/main.cjs, require('baz') should look up

- `$MOUNT_POINT/foo/bar/node_modules/baz`
- `$MOUNT_POINT/foo/node_modules/baz`
- `$MOUNT_POINT/node_modules/baz`
- If $NODE_PATH is specified, search folders listed in $NODE_PATH
- `$HOME/.node_modules/baz`
- `$HOME/.node_libraries/baz`
- `$PREFIX/lib/node/baz`

Why is it deleting JSDocs and other unrelated comments in this file?

Non-blocking: I wonder if we should simply supply vfs.mountPointURL, then users don't have to convert it...another solution is to provide path methods like vfs.resolve/vfs.resolveAsURL, then users don't need to go with real path methods to build VFS paths. Also what actually happens under the URL conversion should be much simpler, because there won't be any poking (is it Windows? etc.), it's just simple concatenation.

The current description is mixing CommonJS and ESM. It's better to describe different cases more clearly.

You could technically unmount CJS while it is executing too (if you make the vfs object reference available e.g. with globals, then call unmount at the top level of a CJS module being loaded from that VFS).

we should use exact names to avoid ambiguity with other methods that actually use that name

Can we not just do something like

const wrappers = { __proto__: null };
const loaderMethodKeys = ObjectKeys(nativeLoaderMethods);
for (let i = 0; i < loaderMethodKeys.length; ++i) {
  const key = loaderMethodKeys[i];
  wrappers[key] = nativeLoaderMethods[key];
}

Then we can simply use the key to identify overrides, and setLoaderFsOverrides and setLoaderPackageOverrides can be merged into

setLoaderOverrides(overrides) {
  for (let i = 0; i < loaderMethodKeys.length; ++i) {
    const key = loaderMethodKeys[i];
    if (overrides[key]) {
      loaderOverrides.set(key, override);
    } else {
      loaderOverrides.delete(key);
    }
  }
  hasLoaderOverrides = loaderOverrides.size > 0;
}

And then we just exports the wrappers to other modules instead of enumerating them all in the export list below. This means in the future if anything is moved to C++ that leads to an overridable point, we no longer have to add like 4 lines of boilerplate below to hook it up, simply adding a key-value pair in nativeLoaderMethods is enough and everything else is automatic.